1. Copyright Authorization
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
2. Field of the Invention
The field of the present invention relates in general to a system and method for structured computing and communications. More particularly, the field of the invention relates to structured computational cells linked together to form a highly flexible, dynamic computing and communications environment.
3. Background
Traditional notions of computer programming focus upon computer languages which are compiled to form executable code. These languages abstract away from the underlying machine language complexities, and allow a programmer to specify behavior in a more general manner. A compiler translates the program into a detailed machine specific implementation in the form of object code. In conventional procedural programming, the data and behavior of the program (i.e. the executable instructions) are distinct. In addition, these programs typically consist of sequential procedures or modes. As such these programs have a well-defined beginning, middle, and end, with little or no flexibility for the user to vary this predetermined sequence.
Procedural programming has been found inadequate in many respects. First, it does not provide a programmer with a paradigm for modeling real world objects and behavior. In particular, procedural programming is not readily adapted for sharing behavior among different computational units or objects. Second, the behavior of a procedural program at run time is typically determined by its data inputs. Since in the procedural model the data is distinct from the executable instructions, the level to which a user may interact with and modify the behavior of a program is limited. While it is possible to use procedural languages to write programs that are self-modifying, the complexity of the program may become unmanageable.
More recently, Object Oriented Programming (OOP) systems have been developed to overcome some of the limitations of procedural programming. OOP systems are based around objects that contain both data (the object's attributes) and executable code (the object's methods). While procedural languages tend to separate data from the processes that operate on it, OOP systems encapsulate the data that defines an object's attributes along with the methods that define the object's behavior. An object's methods may be accessed by sending a message to the object. For instance, a programmer may define a "Clock" object containing an attribute called "Current Time" (which is simply a variable containing the current time) and a method for displaying the time (which may be executable code that draws a clock on the screen showing the current time). The method might be activated by sending a "Display Time" message to the Clock. Once the Clock object is defined, the programmer may abstract away from its implementation. Rather than remembering how to calculate the current time and draw a clock on the screen, the programmer only needs to send a "Display Time" message to the Clock object.
OOP systems also provide a programmer with another method of abstraction called inheritance. A programmer may define a general class of objects having common attributes and methods. Subclasses may also be defined which inherit the attributes and methods from the parent class, but also add or modify attributes and methods. Thus, complex class hierarchies can be developed to define objects that share common attributes and behavior. To use an object from a particular class or subclass, the programmer simply instantiates an "instance" of the object. For example, a class may be defined called "Clock" with a method for calculating and displaying the current time. Subclasses of "Digital Clock" and "Analog Clock" may be defined that behave just like a Clock object, but display the current time differently--either in digital or analog form respectively. The programmer may use both digital and analog clocks in his program by declaring instances of each. Importantly, inheritance allows a programmer to add additional types of clocks without redefining how the current time is calculated. That ability may be inherited from the parent class--only additional or modified attributes and behavior need to be defined in the subclass.
Another aspect of many OOP systems, particularly OOP graphical user interfaces (GUIs), is that they support a "modeless" model, that is, one not tied to any particular predefined sequence of modes or procedures. These systems introduce the notion of "events." An event is any activity of interest, such as the press of a key on a keyboard or movement of a pointing device. The system responds to an event by sending a message to the currently executing application or object. This allows the sequence of events to be determined dynamically by a user's actions at run time.
While the OOP methodology provides for useful abstraction during development and more dynamic interaction at run time, current OOP systems have several limitations. First, application development in an object-oriented programming language, such as C++, brings with it a host of new complexities which the application developer must somehow manage. For instance, a C++ program of even modest complexities requires the creation and maintenance of immense class hierarchies--sophisticated data structures with complex interdependencies. Thus, while a programmer may encapsulate the complexities of an application in an object-oriented framework, the complexities of the framework itself must be managed. As object hierarchies grow, their own complexity obscures the simplicity of the OOP development model.
Second, the OOP model, while often adhered to during development, is rarely adhered to at run time. The attributes and methods of an object are spread across a number of classes and subclasses, and are not encapsulated at a single location in memory as the conceptual model would suggest. This limits the extent to which objects may be modified and restructured at run time. While OOP abstraction allows a programmer to readily define new objects during development, it is much more difficult for a user to do so at run time. This limitation on the ability to modify, add., and restructure objects at run time means that typical OOP systems cannot capture information and modify behavior based on a pattern of linkages and communicative interrelationships between objects. That is, the structure of the system cannot readily adapt and modify itself in response to interaction with a user or environment.
Neural network models suggest that this may be a major drawback to conventional OOP systems. Neural network models demonstrate that an immense amount of information and behavior may be defined based upon the way that neurons, or other simple computational units, are linked together into patterns of communicative interrelationships. Neural network models, however, tend to be primitive in nature and have failed to develop into a useful program development paradigm such as OOP.
What is needed is a development and computing system that is based upon structured, encapsulated computational units similar in some aspects to objects. Preferably, however, the system should provide the advantages of OOP systems without necessitating the creation and maintenance of complex class hierarchies. Further, such a system should preferably maintain its structure and encapsulation at run time, so that the system may be seamlessly modified based on interaction with a user or environment. The system should support dynamic modification of the internal behavior of the computational units, as well as the linkages and relationships among the units. The computational units should provide a basic structure that allows the system to be incrementally scaled to encompass different levels of complexity. Furthermore, it is preferred that the linkages among the basic computational units readily support massively parallel and distributed processing.
It is also desirable that such a computing system map across telecommunications networks. Generally, telecommunications systems of any sophistication are implemented as combinations of computers and interconnecting transmission lines. By design such networks are content-neutral--that is they do not discriminate based on the content of the messages they transport, provided the messages are supplied within defined constraints. Transmission lines are designed to be as nondistorting to the messages as possible, and nodes in the network are treated as "black boxes" whose internal operations--however diverse--are treated as irrelevant to the message traffic being handled by the network.
Intended to be content neutral, communications networks have accrued their own overwhelming complexities, quite apart from the arbitrary features of the messages passing through the system. Similar to procedural programming models, the data is isolated from the processes handling it. What is desired is a computing and communications system that allows the operation of a network and its components to be described in the same form as the content contained in the nodes and transported across the transmission lines of the network. In the ideal expansion of this concept, the entire telecommunications network assumes the capabilities of a general-purpose programmable computer serving its many users; although more limited expressions of the concept may provide for a mix of content-neutral transport of messages and programming of the network. What is desired is a computing and communications system that provides for the programming of the entire communications network in the same terms as the programming of individual computers (which may comprise nodes of the network).
Therefore, what is needed is the seamless integration of data, communications and procedure into a structured computing and communications environment. The behavior of such a system should not only account for data and procedures, but also the linkages and communicative relationships in the environment. Preferably, the system should be incrementally scalable, reuse tested atomic units of computation that are encapsulated and relocatable within the system, support highly parallel and distributed processing, and allow dynamic self-modification. In addition, the system should preferably support the dynamic acquisition of information not only through the acquisition of data and the modification of procedural code, but also through the encoding of information and behavior into the structure of the computing environment.